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[57] ABSTRACT 

A technique for issuing and revoking user certificates of 
authenticity in a public key cryptography system, 
wherein certificates do not need expiration dates, and 
the inconvenience and overhead associated with routine 
certificate renewals are minimized or avoided entirely. 
A Certification Authority issues certificates as required, 
and issues a blacklist having a start date, an expiration 
date, and an entry for every invalid certificate issued 
after the start date. Users assume that every certificate 
issued prior to the blacklist start date is invalid, and that 
invalid certificates issued after the start date will be 
included in the current blacklist, A new blacklist is 
issued prior to expiration of the current one, and the 
blacklist start date is changed only when the blacklist 
becomes unmanageably long. 
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ducc transformations that arc mutual inverses, the appli- 
METHOD OF ISSUANCE AND REVOCATION OF cation of Bs private key to the encrypted message re- 

CERTIFICATES OF AUTHENTICITY USED IN suits in regeneration of the original message. 
PUBLIC KEY NETWORKS AND OTHER SYSTEMS i n summary, then, a public key system ensures au- 

5 thenticity because only the sender A has knowledge of 
BACKGROUND OF THE INVENTION the sender's private key. The message transformed by 

This invention relates generally to communications means of A's own private key is, in effect, a digital 
and other systems to which users gain access by being in "signature" of the message by A. When the receiver B 
possession of a valid certificate of authenticity. Access applies A's public key to the encrypted message and 
to the system may be for the purpose of communicating 10 obtains a clear and intelligible message, this is confirma- 
with other users, retrieving secure information, or re- tion that the message originated from user A, and not 
ceiving a service. More particularly, the invention re- from some other user. Also, since only B has knowledge 
lates to public key network security technology. of his (B's) private key, only B can decrypt the message, 

Public key encryption is a method of secure comrou- and secrecy is thereby preserved, 
nication in which each user has a public encryption key 13 a well known deficiency in such systems is that an 
and a private encryption key, and two users can com- imposter may easily deceive one of the parties. For 
municate knowing only each other's public keys. An example, an imposter A/ may pretend to be A, telling B 
encryption key is a code or number, which, when taken ^ A » s pub ]i c ^ cy , s ^'s public key, thereby convinc- 
together with an encryption algorithm, defines a unique mg B t0 accept a message that purports to be from A, 
mathematical transformation, used to encrypt or de- 20 but is really from the i mpost er A/. Similarly, an impos- 
crypt data. A public key system may be used in such a ter B ^ coul(J contact user A and sa y> m effect. "I am B 
way as to ensure secrecy of the data or message being m6 hefe - s my pubUc kgy g v[ng A instead his (B/s) 
transmitted, i.e. to ensure that the message may not be bHc k u$cr A WQuld thcn send ft requested mes . 
understood by an eavesdropper as well as to ensure the thinking it was going to B. The imposter B; 

authenticity of fhe aoder of the message. ^ prwwrt J J £ ^ m without difficultyi 

mvention is concerned both with the authenticity issue, ^JZ^ u„ 

i* whether a user is who he purports to be and -„g ta «mj pnva* *y authenticatjon prob . 

whether he is authorized to receive certain information, loucai wuu wulu ™ "*„ t < ati ^ ~- ;j w-c th* 

and with the protection of privacy, by assuring that m systems use aut hem cation 

messages are encrypted under the.right keys. 30 basic function of which is to vouch for ^ *^*bP 

There are various types of public key systems. Some between a public key and die person or entity to which 
provide only digital signatures; others provide encryp- it belongs. In the example discussed above, a real user B 
tion only; and still others provide neither, but authenti- would have a certificate that says, in effect, that B is the 
caie by means of a series of messages. For purposes of true owner of a particular public key. User A would 
explanation, this specification describes an encryption 35 then not be fooled into believing that imposter B/ was B, 
technique known as an RSA scheme (named after the since By would not have an appropriate certificate au- 
originators: Rivest, Shamir and Adleman). It will be thenticating him as the owner of B's public key. A cer- 
understood by those knowledgeable in the art of cryp- tificate is a cryptographically signed message indicating 
tography that the principles of the invention can be that a trusted authority vouches for the relationship 
applied equally well to public key systems of other 40 between a public key and a named principal or owner of 
types. the key. Each certificate is "signed" by the trusted au- 

The manner in which a public key cryptography thority, known as the Certification Authority, to ensure 
system operates to ensure authentication is relatively authenticity of the certificate itself. Certificates may be 
simple and may be understood without reference to the ^eld by their owners, who present copies to other users 
mathematical transformations that are used for encryp* 45 wnom they wish to communicate, or may be 
tion and decryption. In sending a message, a user A posted in a public place. In the context of a communica- 
encrypts it for authenticity by transforming it using his tion network, a "public place" is any user-accessible file 
private key (known only to user A). Another user B QJ . record 

receiving the message decrypts it using A's public key, The cert if lcates m2i y a i so employ a public key cryp- 
which A had provided or which B had obtained from a 50 tography system t0 pro duce digital signatures, but this 
public directory. In public key cryptography systems, a nee(J nQt necessari]y be the game system as the one for 
user's public and private keys are selected such that the wfaich . afc ^ published. Basically, the use of 
transformations that they effect are mutual inverses of certificates reduces ^ number of public keys of whicn 
each other That is to say the sequential application of ^ ^ m some manncr outside 

both transformations ^ * e " 55 the communication system. To communicate with mul- 

onginal form .More specifically, A s message, having - destinations , a user must obtain knowledge of a 

been encrypted by w^rtm of A^s ^ k for ^ destination . But if certifica g tes « 

^^^^t^I^Z^ U the user nee. .only ^-JjJWf of one 

nothing to do with maintaining the secrecy of the mes- 60 P^hc key, that of the C«fic^ 

sage, since anybody with knowledge of A's public key For complete network security, every user must have 

could effect the same decryption and obtain access to a certificate. Sometimes, however, it is necessary to 

theoriginal message. Encryption forsecrecy of thedata invalidate certificates; for example, when an employee 

involves a second layer of encryption and decryption. is fired or transferred, or when a password falls into the 

Basically, user A encrypts for secrecy by performing a 65 wrong hands. There are two common mechanisms for 

transformation using B's public key, and user B de- accomplishing this: issuing certificates with expiration 

crypts by performing a transformation using his (B's) dates that define relatively short validity periods, and 

private key. Since B's public and private keys also pro- establishing a "blacklist 1 * of invalid certificates. 
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Typically, certificates have expiration dates of a year, 
or some shorter period, after their issue dates. Before 
the expiration date of his certificate, each user must 
apply to the Certification Authority for a new signed 
certificate with a new expiration date. This mechanism 
has the problem that if certificate expiration times are 
relatively short, then the overhead of reissuing certifi- 
cates can be excessive. Reissuing certificates requires 
that the Certification Authority perform cryptographic 


of periodic certificate renewals is avoided. A blacklist 
has a start date and an expiration date, and any certifi- 
cates issued prior to the start date are automatically 
considered invalid. 

Briefly, and in general terms, the method comprises 
the steps of issuing a signed certificate for each user of 
the system, wherein the signed certificate contains an 
issue date and any other desired public information 
pertaining to the user, such as a public key; issuing a 


processing for each certificate and that the renewed 10 signed blacklist containing a blacklist start date, a black- 


certificates be communicated to all parties that store 
them. If certificates are stored in off-line media, this can 
be particularly inconvenient. In some cases, such as 
when "smart" cards are used, certificate renewal may 
require a face to face meeting between the user and the 15 
Certification Authority. Any attempt to alleviate this 
problem, by increasing the expiration times, poses addi- 
tional problems. A fired and possibly disgruntled em- 
ployee may possess an unexpired certificate, giving him 
a period as long as several months or more in which to 20 
access the network and possibly work mischief. 

This latter problem has given rise to the second 
mechanism for invalidating certificates, which supple- 
ments the first and is referred to as "blacklisting." The 
Certification Authority issues a signed "blacklist" peri- 25 
odically or on demand, containing a list of the certifi- 
cates that have been issued in the past, but which are 
now to be considered invalid. Since the blacklist will 
normally be short, it can be issued with much greater 
frequency than the individual certificates. Anyone who 30 
wishes to verify that a certificate is valid must first 
check that the certificate has not expired, and then that 
the certificate is not included in a current blacklist is- 
sued by the Certification Authority. As in the case of 
the certificates themselves, blacklists may be presented 
by the certificate holders to persons with whom they 
wish to communicate, or may be posted in a public 
place. Someone verifying the authenticity of a certifi- 
cate holder may in some cases require that the blacklist 
be a very recent one, or that a new one be obtained. 

Even when blacklists are used, certificates must still 
have expiration dates. If they did not, the blacklists 
would in time grow to be so long as to be a totally 
impractical mechanism. As invalid certificates expire, 
they can be routinely removed from the blacklist, to 45 
keep the list short and manageable. 

A known alternative approach used in validating 
certificates is to accept a certificate if it has not expired 
and no unexpired blacklist can be found. Another 
known alternative approach is to accept a certificate if 50 
it has not expired and if the latest blacklist has expired, 
but not "too long" ago. Both these alternatives are less 
secure but more robust approaches compared with sim- 
ply invalidating a certificate if the only available black- 
list has expired. 55 

It will be appreciated from the foregoing, however, 
that, even with the use of blacklists, there are inherent 
difficulties, overhead and inconvenience associated 
with the use of authentication certificates that must be 


35 


40 


list expiration date, and an entry for each user whose 
certificate was issued after the blacklist start time and is 
to be considered invalid; and determining whether a 
user's certificate is valid by first obtaining a copy of the 
certificate and a copy of the signed blacklist, then deter- 
mining whether the certificate issued after the blacklist 
start date and is not on the blacklist, in which case the 
certificate is presumed to be valid. 

In the context of the present invention, the term 
"user" includes any person, program, computer, or 
other entity that makes use of an information system or, 
more specifically, a public key cryptography system. 

More specifically, the step of determining whether a 
user's certificate is valid further includes determining 
whether the blacklist has expired; and, if not, continuing 
with the step of determining whether the certificate 
issued after the blacklist start date and is not on the 
blacklist. There are several alternative options that can 
be followed if the blacklist has expired. The first is 
simply to presume that the certificate under consider- 
ation is invalid. The second is to determine whether the 
blacklist has a default expiration date that has passed. 
Although certificate expiration dates are no longer 
needed in accordance with the invention, each blacklist 
may include a default expiration date, which applies to 
all certificates with issue dates after the blacklist start 
date. If the blacklist has expired and the default blacklist 
expiration date has also passed, the certificate is consid- 
ered invalid. But if the blacklist has expired and the 
default expiration date has not passed, the certificate 
may be considered valid if it is not included in the black- 
list and it was issued after the blacklist start date. 

A third option to be followed if the blacklist has 
expired is to determine whether the blacklist expiration 
date was more than some selected time earlier. If so, the 
certificate is presumed invalid. If not* the certificate is 
presumed valid if it is not included in the blacklist and if 
its issue date is after the blacklist start date. 

The method of the invention further comprises the 
step of issuing a new blacklist prior to the blacklist 
expiration date. The step of issuing a new blacklist in- 
cludes determining whether the current blacklist is 
longer than a selected length; and, if so, selecting a new 
start date for the new blacklist, to provide for a shorter 
blacklist. If a new blacklist start date is used, the method 
further includes a step of advising holders of valid cer- 
tificates issued prior to the new blacklist start date that 
these certificates must be renewed to remain valid. It is 
also possible to renew certificates in advance of issuing 


periodically renewed. The present invention provides a 60 a blacklist which revokes the certificates they replace, 
- - * * thus permitting a time interval in which to distribute 

those certificates. 
It will be appreciated from the foregoing summary 


novel alternative approach to the ones discussed above. 
SUMMARY OF THE INVENTION 

The present invention resides in a method for authen- 
ticating users of an information system and, more specif- 
ically, users of a public key cryptography system. In the 
method of the invention, certificates are not required to 
have an expiration date, so much of the inconvenience 


that the present invention represents a significant ad- 
65 vance in information and communication systems that 
employ user authenticity certificates. In particular, the 
invention does not require that certificates have expira- 
tion dates, thereby avoiding the inconvenience and 
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overhead associated with frequent certificate renewals. A well known difficulty with public key systems of 
When the blacklist becomes too long, it can be short- this type is that an imposter B; may pretend to be B, 
ened by choosing a new blacklist start date, and issuing presenting A with his (the imposter's) public key and 
renewed certificates to replace old valid certificates asking for information, which he may then easily de- 
issued prior to the new blacklist start date. 5 crypt, if it has been encrypted using the public key 
The principal advantage of the invention is that cer- supplied by the imposter. A parallel problem is pres- 
tificates must be issued only when the blacklist gets too ented in authenticating the sender A, who may be im- 
long. In the prior art, certificates must be issued periodi- personated by an imposter A/, presenting his own (A/s) 
cally, where the period is determined by the time in public key as A's. 

which the blacklist might get too long. The invention is 10 The use of certificates arose to address these prob- 

most beneficial in situations where blacklisting takes lems. A certificate is a digitally signed message indicat- 

place infrequently, but involves large numbers of revo- ing that a trusted authority (the Certification Authority) 

cations, such as during a corporate reorganization. vouches for the relationship between a public key and 

Other aspects and advantages of the invention will be- its owner. In the example given above, a certificate for 

come apparent from the more detailed description, 15 B states, in effect, that B is the legitimate owner of 

taken in conjunction with the accompanying drawings, public key E* The certificate may also contain other 

of which the following is a brief description. information about B, concerning his employment, for 

example. The certificate is signed by the Certification 

BRIEF DESCRIPTION OF THE DRAWINGS Authority and is, therefore, acceptable to A as proof 

FIG. 1 is flowchart showing the steps of the method »> that B is the rightful owner of the public key E* Under 

of the present invention performed by a Certification the certificate system, an imposter having a different 

Authority; and public key will be unable to convince A to send a mes- 

FIG. 2 is a flowchart showing the steps of the method sage to him, or to convince B to accept a message from 

performed a user in verifying the authenticity of an- mm * t ■ 

other user in accordance with the invention. 2 * Certificates provide a desired verification of the rela- 
tionship between public keys and their nghtful owners, 

DESCRIPTION OF THE PREFERRED but difficulties still arise when there is a need to invali- 

EMBODIMENT date certificates, such as when an employee is fired. In 

As shown in the drawings for purposes of illustration, the prior art. each certificate also contains an "piration 

the present invention is concerned with a method for » date some trae in the future, often up o a year after the 

verifying the authenticity of a user of an information lssue The use of expiration dates in certificates 

system, such as a communication network using public ensures that someone who has no further need for ac 

key cryptography. In a public key system, each user has »° « information system such as a commumca- 

two cryptographic keys: a private key known only to , t.ons network, will at least be denied access when his 

the user, and public key that is not kept secret. The two » exp,res. To 

keys have the property that, when used in conjunction f* 1 <*"**»• W"™ 0 !}%?™ n VJZZ^ 

transformations that are mutual wenes. Th« t0 say periodica „ y or on request . The blacklist contains 

.fa message is encrypted using one of the keys >t can be P ^ unexpired certificate that should be 

decrypted using the other J«J^Ho™*£ * e cons id7red invalid for some reason. Therefore, a user 
nature of the encryption algorithm » such that the pn* authenticity of another user's pub- 

vate key cannot be easily d,s covered rem knowledge Uc ke / must ch ^ k firet t0 dete ^ ine if there b an u P nex . 

of the public key and the algorithm itself pired certificate for the other user, and then check a 

In symbolic terms, ,f user A has a private key and £ k determine whether the other user's 

a public key E A , A can digitally "sign • a message M, by has been mva)jdated . 

encrypting it using^the private key D,,, producing a Th( . ior ^ oach imposes s i gnificant inconve - 

signed message C=D,(M) If the message is directed to nience ^ a „ Qf wfao mnst eriodically obtain 

another user B. B can verify that the message is appro- ncw from ^ Certification Authority. If the 

pnately signed by A, by applying a transformation to w renewa , rio(J b made , Qng enQUgh w minimize this 

the message using A s public key E A , the transformation inconvenience> the b i ack]ist may gr0 w to an unwieldy 

being represented by: size tnere b y increasing system overhead in distributing 

f fo-E tn fvni=M il t0 user5, 0n thc other nand ' kce P in 6 blacklist to a 

A ' t - AlUAM " „, ore manageable size requires that the certificates be 

If the message is to be encrypted for secrecy as well as 55 renewed more frequently, with increased inconve- 

for authenticity, user A will also transform the signed 

message using B's public key Ea thus: ^ certificates that „ e not required 

C=Eb(Pa(M)). to nave 3,1 expiration date, and issues a blacklist contain- 

60 ing a start date, an expiration date, and a list of any 
Then user B will effect two transformations on the certificates that are to be considered invalid, and which 
encrypted and signed message he receives, using A's have issued since the start date. Any certificates issued 
public key E A to verify the authenticity of the sender A, prior to the blacklist start date arc also considered in- 
and B's private key D*to decrypt the message for se- valid. Because certificates no longer need to be re- 
crec r 65 newed, the inconvenience and overhead associated 

with the renewal process are greatly reduced. A new 
EdDdC))=E A iD A {EdLD A {M))))=M- blacklist, with a new expiration date, is issued prior to 

the expiration date of the previous one. The new black- 
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list wilt usually have the same start date, and therefore 
will contain the same invalid certificates as in the previ- 
ous list, plus any additional certificates that have been 
invalidated since the printing of the previous list. 

Only when the blacklist becomes too long to be con- 5 
veniently managed is a new start date selected. Before 
the new start date, all valid certificates issued between 
the old start date and the new start date must be re- 
newed. Typically, however, and depending on the rate 
at which certificates are invalidated, the lifetime of each 10 
certificate is much longer than would be the case if the 
renewal process were needed as the primary mechanism 
to invalidate certificates. 

The steps followed by the Certification Authority in 
accordance with the invention are shown in FIG. 1. On 15 
the first occasion that the new system is used, as deter- 
mined in block 10, the blacklist start date is set to a 
selected date, such as the current date, as indicated in 
block 12. Then the blacklist expiration date is set to 
some selected date in the future, as indicated in block 20 
14, If any previously valid certificates are to be invali- 
dated, as determined in block 16, they are added to the 
blacklist, as indicated in block 18. Then a new blacklist 
is issued (block 20), meaning that it is posted in an acces- 
sible place in the system, or possibly distributed to users 25 
of the system. 

Block 22 indicates the other major function of the 
Certification Authority, issuing any new certificates 
that are needed. The certificate issuing function contin- 
ues from time to time until near the expiration date of 30 
the previously issued blacklist, as determined in block 
24. If the present blacklist is too long to be conveniently 
managed, as determined in block 26, a new start date is 
selected (in block 28), to shorten the blacklist as much as 
desired. If the current date is selected as the new start 35 
date, the blacklist will be reduced to zero, but all re- 
maining valid certificates will need to be renewed. If the 
list is not too long, as determined in block 26, the old 
start date is retained (block 30). Regardless of which 
start date is used, the next step after those indicated in 40 
blocks 28 and 30 is to set a new blacklist expiration date 
(block 14), after which any certificates that need to be 
added to the list are added (block 18), and the new 
blacklist is issued (block 20). 

From a user standpoint, the steps that are performed 45 
in accordance with the invention are those shown in 
FIG. 2. If a first user wishes to verify the authenticity of 
another user, he first obtains a copy of the other user's 
certificate and a copy of the blacklist. If the blacklist has 
not expired, as determined in block 40, the first user 50 
determines (in block 42) whether the issue date of the 
certificate is prior to the blacklist start date. If so, the 
certificate is considered to be invalid, as indicated in 
block 44. If not, the first user searches the blacklist for 
the certificate. If the certificate is found in the blacklist 55 
(block 46), a conclusion of invalidity is also reached. If 
the certificate is not in the blacklist, it is assumed to be 
valid, as indicated in block 48. 

What the first user does if the blacklist has expired 
depends on which of three options is selected in imple- 60 
menting the method. In the simplest variant of the 
method, the certificate is assumed to be invalid if the 
blacklist has expired. This is shown as variant A in FIG. 
2. Two other approaches, referred to as variants B and 
C in FIG. 2, have counterparts in the prior art. The 63 
approach in variant B is to employ a date known as the 
default expiration date on each blacklist. This is an 
expiration date that may be assigned to each blacklist, 


8 

but the date is not used except in the case that the only 
available blacklist has expired. Then, if the default expi- 
ration date has also passed, as determined in block 50, 
the certificate is assumed to be invalid (block 44). If the 
default expiration date has not expired (block 50), the 
certificate may be valid, and processing continues in 
block 42 to make a determination of validity. The third 
option, indicated as variant C in FIG. 2, is to inspect the 
time for which the blacklist has been expired. If the 
blacklist has been expired longer than some preselected 
time T, as determined in block 52, the certificate is 
assumed to be invalid (block 44). Otherwise, the certifi- 
cate may be valid, and processing continues in block 42, 
For all three variants, the invention performs better 
than its prior art counterpart. 

It will be understood that the references to dates in 
the foregoing description could easily be replaced by 
references to certificate sequence numbers. Thus a start 
date could be a starting certificate sequence number. 
Something else to keep in mind is that, although certifi- 
cate expiration dates are no longer necessary in the 
method of the present invention, certificates may still be 
given expiration dates for other purposes, unrelated to 
the revocation of certificates. For example, the renewal 
date could serve as a reminder for employees to obtain 
new identification cards or photographs every few 
years. Such a long-term renewal cycle would also serve 
to allow the blacklist to be periodically shortened with- 
out the need for mass renewals of certificates. 

It will be appreciated from the foregoing that the 
present invention represents a significant advance in the 
field of information systems in which multiple users 
need to obtain authentication of each other's identities 
before permitting access to certain restricted informa- 
tion. In particular, the invention provides a modified 
authentication certificate and blacklist technique in 
which certificates do not need to have expiration dates, 
thereby avoiding frequent and inconvenient certificate 
renewal cycles. It will also be appreciated that, al- 
though an embodiment of the invention has been de- 
scribed in detail for purposes of illustration, various 
modifications may be made without departing from the 
spirit and scope of the invention. Accordingly, the in- 
vention is not to be limited except as by the following 
claims. 

We claim: 

1. A method for authenticating users of an informa- 
tion system, comprising the steps of: 

issuing a signed certificate for each user of an infor- 
mation system, wherein the signed certificate con- 
tains an issue date, a unique public key associated 
with the user, and other public information pertain- 
ing to the user, and wherein a valid certificate is 
one that authenticates an association between the 
user and the public key contained in the certificate, 
and an invalid certificate is one for which the asso- 
ciation between the user and the public key is no 
longer valid; 

issuing a signed list of invalid certificates, referred to 
as a blacklist, containing a blacklist start date, a 
blacklist expiration date, and an entry for each user 
whose certificate was issued after the blacklist start 
date and is invalid; and 

determining whether a user's certificate is valid by 
first obtaining a copy of the certificate and a copy 
of the signed blacklist, then determining whether 
the blacklist has expired, and then, if the blacklist 
has not expired, determining whether the certifi- 
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cate issued after the blacklist start date and is not on 
the blacklist, and is therefore valid. 

2. A method as defined in claim 1, and further com- 
prising: 

if the blacklist has expired, concluding that the certifi- S 
cate is invalid. 

3. A method as defined in claim 1, and further com- 
prising: 

if the blacklist has expired, determining whether the 
blacklist has a default expiration date that has 10 
passed; 

if the blacklist has a default expiration date that has 
not passed, concluding that the certificate is in- 
valid; and 

if the blacklist has a default expiration date has not 15 
passed, continuing with the step of determining 
whether the certificate issued after the blacklist 
start date and is not on the blacklist. 

4. A method as defined in claim 1, and further com- 
prising: . 20 

if the blacklist has expired, determining whether the 
blacklist expired more than a selected time earlier; 

if the certificate expired more than a selected time 
earlier, concluding that the certificate is invalid; 
and 25 

if the certificate expired less than a selected time 
earlier, continuing with the step of determining 
whether the certificate issued after the blacklist 
start date and is not on the blacklist. 

5. A method as defined in claim and further compris- 30 
ing: 

issuing a new blacklist prior to the blacklist expiration 
date. 

6. A method as defined in claim 5, wherein the step of 
issuing a new blacklist includes: 35 

determining whether the current blacklist is longer 
than a selected length; and, if so, 

selecting a new start date for the new blacklist, to 
provide for a shorter blacklist, and advising holders 
of valid certificates issued prior to the new blacklist 40 
start date that these certificates must be renewed to 
remain valid. 

7. A method for authenticating users of a public key 
cryptographic system, comprising the steps of: 

issuing a signed certificate for each user of a public 45 
key cryptographic system, wherein the signed cer- 
tificate contains an issue date, a unique public key 
associated with the user, and other public informa- 
tion pertaining to the user, and wherein a valid 
certification is one that authenticates an association 50 
between the user and the public key contained in 
the certificate, and an invalid certificate is one for 
which the association between the user and the 
public key is no longer valid; 

issuing a signed list of invalid certificates, referred to 55 
as a blacklist, containing a blacklist start date, a 
blacklist expiration date, and an entry for each user 
whose certificate was issued after the blacklist start 
date and is invalid; and 

determining whether a user's certificate is valid by 60 
first obtaining a copy of the certificate and a copy 
of the signed blacklist, then determining whether 
the blacklist has expired, and then, if the blacklist 
has not expired, determining whether the certifi- 
cate issued after the blacklist start date and is not on 65 
the blacklist, and is therefore valid. 

8. A method as defined in claim 7, and further com- 
prising: 
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if the blacklist has expired, concluding that the certifi- 
cate is invalid. 

9. A method as defined in claim 7, and further com- 
prising: 

if the blacklist has expired, determining whether the 
blacklist has a default expiration date that has 
passed; 

if the blacklist has a default expiration date that has 
passed, concluding that the certificate is invalid; 
and 

if the blacklist has a default expiration date that has 
not passed, continuing with the step of determining 
whether the certificate issued after the blacklist 
start date and is not on the blacklist. 

10. A method as defined in claim 7, and further com- 
prising: 

if the blacklist has expired, determining whether the 
blacklist expired more than a selected time earlier; 

if the certificate expired more than a selected time 
earlier, concluding that the certificate is invalid; 
and 

if the certificate expired less than a selected time 
earlier, continuing with the step of determining 
whether the certificate issued after the blacklist 
start date and is not on the blacklist. 

11. A method as defined in claim 7, and further com- 
prising: 

issuing a new blacklist prior to the blacklist expiration 
date, 

12. A method as defined in claim 11, wherein the step 
of issuing a new blacklist includes: 

determining whether the current blacklist is longer 
than a selected length; and, if so, 

selecting a new start date for the new blacklist, to 
provide for a shorter blacklist, and advising holders 
of valid certificates issued prior to the new blacklist 
start date that these certificates must be renewed to 
remain valid. 

13. A method for authenticating users of a public key 
cryotpgraphic system, comprising the steps of: 

issuing a signed certificate for each user of a public 
key cryptographic system, wherein the signed cer- 
tificate contains an issue sequence number, a unique 
public key associated with the user, and other pub- 
lic information pertaining to the user, and wherein 
a valid certificate is one that authenticates an asso- 
ciation between the user and the public key con- 
tained in the certificate, and an invalid certificate is 
one for which the association between the user and 
the public keyls no longer valid; 

issuing a signed list of invalid certificates, referred to 
as a blacklist, containing a blacklist start sequence 
number, a blacklist expiration date, and an entry for 
each user whose certificate has a sequence number 
greater than the blacklist start sequence number 
and is to be considered invalid; and 

determining whether a user's certificate is valid by 
first obtaining a copy of the certificate and a copy 
of the signed blacklist, then determining whether 
the blacklist has expired, and then, if the blacklist 
has not expired, determining whether the certifi- 
cate has a sequence number greater than the black- 
list start sequence number and is not on the black- 
list, and is therefore valid. 

14. A method as defined in claim 13, and further 
comprising: 

if the blacklist has expired, concluding that the certifi- 
cate is invalid. 
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15. A method as defined in claim 13, and further 
comprising: 

if the blacklist has expired, determining whether the 
blacklist has a default expiration date that has 
passed; 5 

if the blacklist has a default expiration date that has 
passed, concluding that the certificate is invalid; 
and 

if the blacklist has a default expiration date that has 
not passed, continuing with the step of determining 10 
whether the certificate has a sequence number 
greater than the blacklist starting sequence number 
and is not on the blacklist. 

16. A method as defined in claim 13, and further 
comprising: 15 

if the blacklist has expired, determining whether the 
blacklist expired more than a selected time earlier; 

if the certificate expired more than a selected time 
earlier, concluding that the certificate is invalid; 
and 20 


if the certificate expired less than a selected time 
earlier, continuing with the step of determining 
whether the certificate has a sequence number 
greater than the blacklist staring sequence number 
and is not on the blacklist. 

17. A method as defined in claim 13, and further 
comprising: 

issuing a new blacklist prior to expiration of the 
blacklist. 

18. A method as defined in claim 17, wherein the step 
of issuing a new blacklist includes: 

determining whether the current blacklist is longer 
than a selected length; and, if so, 

selecting a new start sequence number for the new 

blacklist, to provide for a shorter blacklist, and 

advising holders of valid certificates issued with 

sequence numbers smaller than the new blacklist 

start sequence number that these certificates must 

be renewed to remain valid. 

♦ * * * * 
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